Building automation systems encompass a wide variety of systems that aid in the monitoring and control of various aspects of building operation. Building automation systems include security systems (including access control systems and/or CCTV systems), fire or life safety systems, lighting systems, and comfort systems, sometimes referred to as heating, ventilation, and air conditioning (“HVAC”) systems. In large commercial and industrial facilities, such systems have an extensive number of elements and are highly automated.
The elements of building automation systems are widely dispersed throughout a facility. For example, a comfort or HVAC system typically includes large numbers of temperature sensors and ventilation damper controls, as well as other elements, which are located in virtually every area of a facility. Similarly, a security system may have intrusion detection, motion sensors and alarm actuators dispersed throughout an entire building or campus. Fire safety systems also include widely dispersed devices in the form of smoke alarms, pull stations and controllers. To achieve efficient and effective building automation system operation, there is a need to monitor the operation of, and often communicate with, the various dispersed elements of a building automation system.
To this end, building automation systems typically have one or more centralized control stations in which data from the system may be monitored, and in which various aspects of system operation may be controlled and/or monitored. The control station typically includes a computer having processing equipment, data storage equipment, and a user interface. To allow for monitoring and control of the dispersed control system elements, building control systems often employ multi-level communication networks to communicate operational and/or alarm information between operating elements, such as sensors and actuators, and the centralized control station.
In older systems, control stations provided building control data in a cumbersome, text-oriented format. The control station presented data in a way that typically required intimate system knowledge to interpret and understand. As building automation systems become more complex, it has become increasingly advantageous to present building system data in a more intuitive manner. To address this issue, control stations of building automation systems now generally employ graphical user interfaces that combine text information with representative graphics to illustrate the context of the system data being displayed. Graphics can include graphically displayed maps, floor plans, diagrams of complex equipment, and even graphic display of controlled or sensed values.
An example of the use of representative graphics may be the use of a thermometer shaped graphic to represent a temperature reading, as opposed to a simple text value. Similarly, the alarm status for a floor of building may be represented on a graphical display of the building floor plan, as opposed to a simple text list of alarm locations.
While the use of graphics and other advanced interface features have enhanced access and monitoring of building system data, one limitation on control stations is the manner in which information regarding different devices and subsystems is acquired. Because building systems can involve products from a wide variety of manufacturers, it can be cumbersome for various output-generating operations to acquire data from the various products and subsystems. Such output-generating operations can include those that provide graphical user interfaces to system data, reporting, commanding, alarming and data logging. Such operations must account for the fact that different manufacturers may present different formats of device output data.
For example, one temperature sensor may provide status data as a single value between 0 and 14, and another temperature sensor may provide status data as multiple binary values representative of degrees Celsius. In such a case, an output generating operation would need separate ways of handling the two sensor data formats. A drawback of this arrangement is that every new operation or application must account for different presentations of data from various devices.
There is a need, therefore, for a more intuitive interface that allows for a more uniform access to data of devices and subsystems in building automation systems by output-generating operations that does not require specific programming for every different brand or style of building automation system device.